<div class="tmd-doc">
<h1 class="tmd-header-1">
Constants and Variables
</h1>
<p></p>
<div class="tmd-usual">
This article will introduce constant and variable declarations in Go. The concept of untyped values and explicit conversions will also be introduced.
</div>
<p></p>
<div class="tmd-usual">
The literals introduced in <a href="basic-types-and-value-literals.html">the last article</a> are all called unnamed constants (or literal constants), except <code class="tmd-code-span">false</code> and <code class="tmd-code-span">true</code>, which are two predeclared (built-in) named constants. Custom named constant declarations will be introduced below in this article.
</div>
<p></p>
<p></p>
<h3 id="untyped-value" class="tmd-header-3">
Untyped Values and Typed Values
</h3>
<p></p>
<div class="tmd-usual">
In Go, some values are untyped. An untyped value means the type of the value has not been confirmed yet. On the contrary, the type of a typed value is determined.
</div>
<p></p>
<div class="tmd-usual">
For most untyped values, each of them has one default type. The predeclared <code class="tmd-code-span">nil</code> is the only untyped value which has no default type. We will learn more about <code class="tmd-code-span">nil</code> in other Go 101 articles later.
</div>
<p></p>
<div class="tmd-usual">
All literal constants (unnamed constants) are untyped values. In fact, in Go, most untyped values are literal constants and named constants (which will be introduced below in the current article). The other untyped values include the just mentioned <code class="tmd-code-span">nil</code> and some boolean results returned by some operations which will be introduced in other articles later.
</div>
<p></p>
<div class="tmd-usual">
The default type of a literal constant is determined by its literal form.
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
The default type of a string literal is <code class="tmd-code-span">string</code>.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
The default type of a boolean literal is <code class="tmd-code-span">bool</code>.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
The default type of an integer literal is <code class="tmd-code-span">int</code>.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
The default type of a rune literal is <code class="tmd-code-span">rune</code> (a.k.a., <code class="tmd-code-span">int32</code>).
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
The default type of a floating-point literal is <code class="tmd-code-span">float64</code>.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
If a literal contains an imaginary part, then its default type is <code class="tmd-code-span">complex128</code>.
</div>
</li>
</ul>
<p></p>
<h3 id="explicit-conversion" class="tmd-header-3">
Explicit Conversions of Untyped Constants
</h3>
<p></p>
<div class="tmd-usual">
Like many other languages, Go also supports value conversions. We can use the form <code class="tmd-code-span">T(v)</code> to convert a value <code class="tmd-code-span">v</code> to the type denoted by <code class="tmd-code-span">T</code> (or simply speaking, type <code class="tmd-code-span">T</code>). If the conversion <code class="tmd-code-span">T(v)</code> is legal, Go compilers view <code class="tmd-code-span">T(v)</code> as a typed value of type <code class="tmd-code-span">T</code>. Surely, for a certain type <code class="tmd-code-span">T</code>, to make the conversion <code class="tmd-code-span">T(v)</code> legal, the value <code class="tmd-code-span">v</code> can't be arbitrary.
</div>
<p></p>
<div class="tmd-usual">
The following mentioned rules apply for both the literal constants introduced in the last article and the untyped named constants which will be introduced soon.
</div>
<p></p>
<div class="tmd-usual">
For an untyped constant value <code class="tmd-code-span">v</code>, there are two scenarios where <code class="tmd-code-span">T(v)</code> is legal.
</div>
<ol class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
<code class="tmd-code-span">v</code> (or the literal denoted by <code class="tmd-code-span">v</code>) is <a href="basic-types-and-value-literals.html#representability">representable</a> as a value of a basic type <code class="tmd-code-span">T</code>. The result value is a typed constant of type <code class="tmd-code-span">T</code>.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
The default type of <code class="tmd-code-span">v</code> is an integer type (<code class="tmd-code-span">int</code> or <code class="tmd-code-span">rune</code>) and <code class="tmd-code-span">T</code> is a string type. The result of <code class="tmd-code-span">T(v)</code> is a string of type <code class="tmd-code-span">T</code> and contains the UTF-8 representation of the integer as a Unicode code point. Integer values outside the range of valid Unicode code points result strings represented by <code class="tmd-code-span">"\uFFFD"</code> (a.k.a., <code class="tmd-code-span">"\xef\xbf\xbd"</code>). <code class="tmd-code-span">0xFFFD</code> is the code point for the Unicode replacement character. The result string of a conversion from an integer always contains one and only one rune. (Note, later Go version might <a href="https://github.com/golang/go/issues/3939">only allow converting rune or byte integers to strings</a>. Since Go Toolchain 1.15, the <code class="tmd-code-span">go vet</code> command warns on conversions from non-rune and non-byte integers to strings.)
</div>
</li>
</ol>
<p></p>
<p></p>
<div class="tmd-callout">
<div class="tmd-callout-content">
<div class="tmd-usual">
In fact, the second scenario doesn't require <code class="tmd-code-span">v</code> to be a constant. If <code class="tmd-code-span">v</code> is a constant, then the result of the conversion is also a constant; otherwise, the result is not a constant.
</div>
</div>
</div>
<p></p>
<div class="tmd-usual">
For example, the following conversions are all legal.
</div>
<pre class="tmd-code disable-line-numbers111">
<code class="language-go">// Rounding happens in the following 3 lines.
complex128(1 + -1e-1000i)  // 1.0+0.0i
float32(0.49999999)        // 0.5
float32(17000000000000000)
// No rounding in the these lines.
float32(123)
uint(1.0)
int8(-123)
int16(6+0i)
complex128(789)

string(65)          // "A"
string('A')         // "A"
string('\u68ee')    // "森"
string(-1)          // "\uFFFD"
string(0xFFFD)      // "\uFFFD"
string(0x2FFFFFFFF) // "\uFFFD"
</code></pre>
<p></p>
<div class="tmd-usual">
And the following conversions are all illegal.
</div>
<pre class="tmd-code disable-line-numbers111">
<code class="language-go">// 1.23 is not representable as a value of int.
int(1.23)
// -1 is not representable as a value of uint8.
uint8(-1)
// 1+2i is not representable as a value of float64.
float64(1+2i)

// Constant -1e+1000 overflows float64.
float64(-1e1000)
// Constant 0x10000000000000000 overflows int.
int(0x10000000000000000)

// The default type of 65.0 is float64,
// which is not an integer type.
string(65.0)
// The default type of 66+0i is complex128,
// which is not an integer type.
string(66+0i)
</code></pre>
<p></p>
<div class="tmd-callout">
<div class="tmd-callout-content">
<div class="tmd-usual">
From the above examples, we know that an untyped constant, (for example <code class="tmd-code-span">-1e1000</code> and <code class="tmd-code-span">0x10000000000000000</code>), may even not be able to represent as a value of its default type.
</div>
</div>
</div>
<p></p>
<div class="tmd-usual">
Please note, sometimes, the form of explicit conversions must be written as <code class="tmd-code-span">(T)(v)</code> to avoid ambiguities. Such situations often happen in case of <code class="tmd-code-span">T</code> is not an identifier.
</div>
<p></p>
<div class="tmd-usual">
We will learn more explicit conversion rules later in other Go 101 articles.
</div>
<p></p>
<h3 id="type-deduce" class="tmd-header-3">
Introduction of Type Deductions in Go
</h3>
<p></p>
<div class="tmd-usual">
Go supports type deduction. In other words, in many circumstances, programmers don't need to explicitly specify the types of some values in code. Go compilers will deduce the types for these values by context.
</div>
<p></p>
<div class="tmd-usual">
Type deduction is also often called type inference.
</div>
<p></p>
<div class="tmd-usual">
In Go code, if a place needs a value of a certain type and an untyped value (often a constant) is representable as a value of the certain type, then the untyped value can be used in the place. Go compilers will view the untyped value as a typed value of the certain type. Such places include an operand in an operator operation, an argument in a function call, a destination value or a source value in an assignment, etc.
</div>
<p></p>
<div class="tmd-usual">
Some circumstances have no requirements on the types of the used values. If an untyped value is used in such a circumstance, Go compilers will treat the untyped value as a typed value of its default type.
</div>
<p></p>
<div class="tmd-usual">
The two type deduction cases can be viewed as implicit conversions.
</div>
<p></p>
<div class="tmd-usual">
The below constant and variable declaration sections will show some type deduction cases. More type deduction rules and cases will be introduced in other articles.
</div>
<p></p>
<h3 id="constant" class="tmd-header-3">
Constant Declarations
</h3>
<p></p>
<div class="tmd-usual">
Unnamed constants are all boolean, numeric and string values. Like unnamed constants, named constants can also be only boolean, numeric and string values. The keyword <code class="tmd-code-span">const</code> is used to declare named constants. The following program contains some constant declarations.
</div>
<p></p>
<pre class="tmd-code line-numbers must-line-numbers">
<code class="language-go">package main

// Declare two individual constants. Yes,
// non-ASCII letters can be used in identifiers.
const π = 3.1416
const Pi = π // &lt;=&gt; const Pi = 3.1416

// Declare multiple constants in a group.
const (
	No         = !Yes
	Yes        = true
	MaxDegrees = 360
	Unit       = "radian"
)

func main() {
	// Declare multiple constants in one line.
	const TwoPi, HalfPi, Unit2 = π * 2, π * 0.5, "degree"
}
</code></pre>
<p></p>
<div class="tmd-usual">
Go specification calls each of the lines containing a <code class="tmd-code-span">=</code> symbol in the above constant declaration group as a <span class="tmd-bold"><span class="tmd-italic">constant specification</span></span>.
</div>
<p></p>
<div class="tmd-usual">
In the above example, the <code class="tmd-code-span">*</code> symbol is the multiplication operator and the <code class="tmd-code-span">!</code> symbol is the boolean-not operator. Operators will be introduced in the next article, <a href="operators.html">common operators</a>.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
The <code class="tmd-code-span">=</code> symbol means "bind" instead of "assign". We should interpret each constant specification as a declared identifier is bound to a corresponding basic value literal. Please read the last section in the current article for more explanations.
</div>
<p></p>
<div class="tmd-usual">
In the above example, the name constants <code class="tmd-code-span">π</code> and <code class="tmd-code-span">Pi</code> are both bound to the literal <code class="tmd-code-span">3.1416</code>. The two named constants may be used at many places in code. Without constant declarations, the literal <code class="tmd-code-span">3.1416</code> would be populated at those places. If we want to change the literal to <code class="tmd-code-span">3.14</code> later, many places need to be modified. With the help of constant declarations, the literal <code class="tmd-code-span">3.1416</code> will only appear in one constant declaration, so only one place needs to be modified. This is the main purpose of constant declarations.
</div>
<p></p>
<div class="tmd-usual">
Later, we use the terminology <span class="tmd-bold"><span class="tmd-italic">non-constant</span></span> values to denote the values who are not constants. The to be introduced variables below, all belong to one kind of non-constant values.
</div>
<p></p>
<div class="tmd-usual">
Please note that, constants can be declared both at package level (out of any function body) and in function bodies. The constants declared in function bodies are called local constants. The constants declared out of any function body are called package-level constants. We also often call package-level constants as global constants.
</div>
<p></p>
<div class="tmd-usual">
The declaration orders of two package-level constants are not important. In the above example, the declaration orders of <code class="tmd-code-span">No</code> and <code class="tmd-code-span">Yes</code> can be exchanged.
</div>
<p></p>
<div class="tmd-usual">
All constants declared in the last example are untyped. The default type of a named untyped constant is the same as the literal bound to it.
</div>
<p></p>
<h4 class="tmd-header-4">
Typed named constants
</h4>
<p></p>
<div class="tmd-usual">
We can declare typed constants, typed constants are all named. In the following example, all the four declared constants are typed values. The types of <code class="tmd-code-span">X</code> and <code class="tmd-code-span">Y</code> are both <code class="tmd-code-span">float32</code> and the types of <code class="tmd-code-span">A</code> and <code class="tmd-code-span">B</code> are both <code class="tmd-code-span">int64</code>.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">const X float32 = 3.14

const (
	A, B int64   = -3, 5
	Y    float32 = 2.718
)
</code></pre>
<p></p>
<div class="tmd-usual">
If multiple typed constants are declared in the same constant specification, then their types must be the same, just as the constants <code class="tmd-code-span">A</code> and <code class="tmd-code-span">B</code> in the above example.
</div>
<p></p>
<div class="tmd-usual">
We can also use explicit conversions to provide enough information for Go compilers to deduce the types of typed named constants. The above code snippet is equivalent to the following one, in which <code class="tmd-code-span">X</code>, <code class="tmd-code-span">Y</code>, <code class="tmd-code-span">A</code> and <code class="tmd-code-span">B</code> are all typed constants.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">const X = float32(3.14)

const (
	A, B = int64(-3), int64(5)
	Y    = float32(2.718)
)
</code></pre>
<p></p>
<div class="tmd-usual">
If a basic value literal is bound to a typed constant, the basic value literal must be representable as a value of the type of the constant. The following typed constant declarations are invalid.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">// error: 256 overflows uint8
const a uint8 = 256
// error: 256 overflows uint8
const b = uint8(255) + uint8(1)
// error: 128 overflows int8
const c = int8(-128) / int8(-1)
// error: -1 overflows uint
const MaxUint_a = uint(^0)
// error: -1 overflows uint
const MaxUint_b uint = ^0
</code></pre>
<p></p>
<div class="tmd-usual">
In the above and following examples <code class="tmd-code-span">^</code> is bitwise-not operator.
</div>
<p></p>
<div class="tmd-usual">
The following typed constant declaration is valid on 64-bit OSes, but invalid on 32-bit OSes. For each <code class="tmd-code-span">uint</code> value has only 32 bits on 32-bit OSes. <code class="tmd-code-span">(1 &lt;&lt; 64) - 1</code> is not representable as 32-bit values. (Here, <code class="tmd-code-span">&lt;&lt;</code> is bitwise-left-shift operator.)
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">const MaxUint uint = (1 &lt;&lt; 64) - 1
</code></pre>
<p></p>
<div class="tmd-usual">
Then how to declare a typed <code class="tmd-code-span">uint</code> constant and bind the largest <code class="tmd-code-span">uint</code> value to it? Use the following way instead.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">const MaxUint = ^uint(0)
</code></pre>
<p></p>
<div class="tmd-usual">
Similarly, we can declare a typed <code class="tmd-code-span">int</code> constant and bind the largest <code class="tmd-code-span">int</code> value to it. (Here, <code class="tmd-code-span">&gt;&gt;</code> is bitwise-right-shift operator.)
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">const MaxInt = int(^uint(0) &gt;&gt; 1)
</code></pre>
<p></p>
<div class="tmd-usual">
A similar method can be used to get the number of bits of a native word, and check the current OS is 32-bit or 64-bit.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">// NativeWordBits is 64 or 32.
const NativeWordBits = 32 &lt;&lt; (^uint(0) &gt;&gt; 63)
const Is64bitOS = ^uint(0) &gt;&gt; 63 != 0
const Is32bitOS = ^uint(0) &gt;&gt; 32 == 0
</code></pre>
<p></p>
<div class="tmd-usual">
Here, <code class="tmd-code-span">!=</code> and <code class="tmd-code-span">==</code> are not-equal-to and equal-to operators.
</div>
<p></p>
<h4 class="tmd-header-4">
Autocomplete in constant declarations
</h4>
<p></p>
<div class="tmd-usual">
In a group-style constant declaration, except the first constant specification, other constant specifications can be incomplete. An incomplete constant specification only contains an identifier list. Compilers will autocomplete the incomplete lines for us by copying the missing part from the first preceding complete constant specification. For example, at compile time, compilers will automatically complete the following code
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">const (
	X float32 = 3.14
	Y           // here must be one identifier
	Z           // here must be one identifier

	A, B = "Go", "language"
	C, _
	// In the above line, the blank identifier
	// is required to be present.
)
</code></pre>
<p></p>
<div class="tmd-usual">
as
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">const (
	X float32 = 3.14
	Y float32 = 3.14
	Z float32 = 3.14

	A, B = "Go", "language"
	C, _ = "Go", "language"
)
</code></pre>
<p></p>
<h4 class="tmd-header-4">
<code class="tmd-code-span">iota</code> in constant declarations
</h4>
<p></p>
<div class="tmd-usual">
The autocomplete feature plus the <code class="tmd-code-span">iota</code> constant generator feature brings much convenience to Go programming. <code class="tmd-code-span">iota</code> is a predeclared constant which can only be used in other constant declarations. It is declared as
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">const iota = 0
</code></pre>
<p></p>
<div class="tmd-usual">
But the value of an <code class="tmd-code-span">iota</code> in code might not always be <code class="tmd-code-span">0</code>. When the predeclared <code class="tmd-code-span">iota</code> constant is used in a custom constant declaration, at compile time, within the custom constant declaration, its value will be reset to <code class="tmd-code-span">0</code> at the first constant specification of each group of constants and will increase <code class="tmd-code-span">1</code> constant specification by constant specification. In other words, in the <span class="tmd-bold"><span class="tmd-italic">n</span></span>th constant specification of a constant declaration, the value of <code class="tmd-code-span">iota</code> is <span class="tmd-bold"><span class="tmd-italic">n</span></span> (starting from zero). So <code class="tmd-code-span">iota</code> is only useful in group-style constant declarations.
</div>
<p></p>
<div class="tmd-usual">
Here is an example using both the autocomplete and the <code class="tmd-code-span">iota</code> constant generator features. Please read the comments to get what will happen at compile time. The <code class="tmd-code-span">+</code> symbol in this example is the addition operator.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

func main() {
	const (
		k = 3 // now, iota == 0

		m float32 = iota + .5 // m float32 = 1 + .5
		n                     // n float32 = 2 + .5

		p = 9             // now, iota == 3
		q = iota * 2      // q = 4 * 2
		_                 // _ = 5 * 2
		r                 // r = 6 * 2
		s, t = iota, iota // s, t = 7, 7
		u, v              // u, v = 8, 8
		_, w              // _, w = 9, 9
	)

	const x = iota // x = 0
	const (
		y = iota // y = 0
		z        // z = 1
	)

	println(m)             // +1.500000e+000
	println(n)             // +2.500000e+000
	println(q, r)          // 8 12
	println(s, t, u, v, w) // 7 7 8 8 9
	println(x, y, z)       // 0 0 1
}
</code></pre>
<p></p>
<div class="tmd-usual">
The above example is just to demo the rules of the <code class="tmd-code-span">iota</code> constant generator feature. Surely, in practice, we should use it in more meaningful ways. For example,
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">const (
	Failed = iota - 1 // == -1
	Unknown           // == 0
	Succeeded         // == 1
)

const (
	Readable = 1 &lt;&lt; iota // == 1
	Writable             // == 2
	Executable           // == 4
)
</code></pre>
<p></p>
<div class="tmd-usual">
Here, the <code class="tmd-code-span">-</code> symbol is the subtraction operator, and the <code class="tmd-code-span">&lt;&lt;</code> symbol is the left-shift operator. Both of these operators will be introduced in the next article.
</div>
<p></p>
<h3 id="variable" class="tmd-header-3">
Variables, Variable Declarations and Value Assignments
</h3>
<p></p>
<div class="tmd-usual">
Variables are named values. Variables are stored in memory at run time. The value represented by a variable can be modified at run time.
</div>
<p></p>
<div class="tmd-usual">
All variables are typed values. When declaring a variable, there must be sufficient information provided for compilers to deduce the type of the variable.
</div>
<p></p>
<div class="tmd-usual">
The variables declared within function bodies are called local variables. The variables declared out of any function body are called package-level variables. We also often call package-level variables as global variables.
</div>
<p></p>
<div class="tmd-usual">
There are two basic variable declaration forms, the standard one and the short one. The short form can only be used to declare local variables.
</div>
<p></p>
<h4 class="tmd-header-4">
Standard variable declaration forms
</h4>
<p></p>
<div class="tmd-usual">
Each standard declaration starts with the <code class="tmd-code-span">var</code> keyword, which is followed by the declared variable name. Variable names must be <a href="keywords-and-identifiers.html#identifier">identifiers</a>.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
The following are some full standard declaration forms. In these declarations, the types and initial values of the declared variables are all specified.
</div>
<pre class="tmd-code line-numbers must-line-numbers">
<code class="language-go">var lang, website string = "Go", "https://golang.org"
var compiled, dynamic bool = true, false
var announceYear int = 2009
</code></pre>
<p></p>
<div class="tmd-usual">
As we have found, multiple variables can be declared together in one variable declaration. Please note, there can be just one type specified in a variable declaration. So the types of the multiple variables declared in the same declaration line must be identical.
</div>
<p></p>
<div class="tmd-usual">
Full standard variable declaration forms are seldom used in practice, since they are verbose. In practice, the two standard variable declaration variant forms introduced below are used more often. In the two variants, either the types or the initial values of the declared variables are absent.
</div>
<p></p>
<div class="tmd-usual">
The following are some standard variable declarations without specifying variable types. Compilers will deduce the types of the declared variables as the types (or default types) of their respective initial values. The following declarations are equivalent to the above ones in fact. Please note, in the following declarations, the types of the multiple variables declared in the same declaration line can be different.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">// The types of the lang and dynamic variables
// will be deduced as built-in types "string"
// and "bool" by compilers, respectively.
var lang, dynamic = "Go", false

// The types of the compiled and announceYear
// variables will be deduced as built-in
// types "bool" and "int", respectively.
var compiled, announceYear = true, 2009

// The types of the website variable will be
// deduced as the built-in type "string".
var website = "https://golang.org"
</code></pre>
<p></p>
<div class="tmd-usual">
The type deductions in the above example can be viewed as implicit conversions.
</div>
<p></p>
<div class="tmd-usual">
The following are some standard declarations without specifying variable initial values. In these declarations, all declared variables are initialized as the zero values of their respective types.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">// Both are initialized as blank strings.
var lang, website string
// Both are initialized as false.
var interpreted, dynamic bool
// n is initialized as 0.
var n int
</code></pre>
<p></p>
<div class="tmd-usual">
Multiple variables can be grouped into one standard form declaration by using <code class="tmd-code-span">()</code>. For example:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">var (
	lang, bornYear, compiled     = "Go", 2007, true
	announceAt, releaseAt    int = 2009, 2012
	createdBy, website       string
)
</code></pre>
<p></p>
<div class="tmd-usual">
The above example is formatted by using the <code class="tmd-code-span">go fmt</code> command provided in Go Toolchain. In the above example, each of the three lines are enclosed in <code class="tmd-code-span">()</code> this is known as variable specification.
</div>
<p></p>
<div class="tmd-usual">
Generally, declaring related variables together will make code more readable.
</div>
<p></p>
<h4 id="assignment" class="tmd-header-4">
Pure value assignments
</h4>
<p></p>
<div class="tmd-usual">
In the above variable declarations, the sign <code class="tmd-code-span">=</code> means assignment. Once a variable is declared, we can modify its value by using pure value assignments. Like variable declarations, multiple values can be assigned in a pure assignment.
</div>
<p></p>
<div class="tmd-usual">
The expression items at the left of <code class="tmd-code-span">=</code> symbol in a pure assignment are called destination or target values. They must be addressable values, map index expressions, or the blank identifier. Value addresses and maps will be introduced in later articles.
</div>
<p></p>
<div class="tmd-usual">
Constants are immutable, so a constant can't show up at the left side of a pure assignment as a destination value, it can only appear at the right side as a source value. Variables can be used as both source values and destination values, so they can appear at both sides of pure value assignments.
</div>
<p></p>
<div class="tmd-usual">
Blank identifiers can also appear at the left side of pure value assignments as destination values, in which case, it means we ignore the destination values. Blank identifiers can't be used as source values in assignments.
</div>
<p></p>
<div class="tmd-usual">
Example:
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">const N = 123
var x int
var y, z float32

N = 9 // error: constant N is not modifiable
y = N // ok: N is deduced as a float32 value
x = y // error: type mismatch
x = N // ok: N is deduced as an int value
y = x // error: type mismatch
z = y // ok
_ = y // ok

x, y = y, x // error: type mismatch
x, y = int(y), float32(x) // ok
z, y = y, z               // ok
_, y = y, z               // ok
z, _ = y, z               // ok
_, _ = y, z               // ok
x, y = 69, 1.23           // ok
</code></pre>
<p></p>
<div class="tmd-usual">
The code at last line in the above example uses explicit conversions to make the corresponding destination and source values matched. The explicit conversion rules for non-constant numeric values are introduced below. Go doesn't support assignment chain. For example, the following code is illegal.
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">var a, b int
a = b = 123 // syntax error
</code></pre>
<p></p>
<h4 class="tmd-header-4">
Short variable declaration forms
</h4>
<p></p>
<div class="tmd-usual">
We can also use short variable declaration forms to declare variables. Short variable declarations can only be used to declare local variables. Let's view an example which uses some short variable declarations.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

func main() {
	// Both lang and year are newly declared.
	lang, year := "Go language", 2007

	// Only createdBy is a new declared variable.
	// The year variable has already been
	// declared before, so here its value is just
	// modified, or we can say it is redeclared.
	year, createdBy := 2009, "Google Research"

	// This is a pure assignment.
	lang, year = "Go", 2012

	print(lang, " is created by ", createdBy)
	println(", and released at year", year)
}
</code></pre>
<div class="tmd-usual">
Each short variable declaration must declare at least one new variable.
</div>
<p></p>
<div class="tmd-usual">
There are several differences between short and standard variable declarations.
</div>
<ol class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
In the short declaration form, the <code class="tmd-code-span">var</code> keyword and variable types must be omitted.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
The assignment sign must be <code class="tmd-code-span">:=</code> instead of <code class="tmd-code-span">=</code>.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
In the short variable declaration, old variables and new variables can mix at the left of <code class="tmd-code-span">:=</code>. But there must be at least one new variable at the left.
</div>
</li>
</ol>
<p></p>
<div class="tmd-callout">
<div class="tmd-callout-content">
<div class="tmd-usual">
Please note, comparing to pure assignments, there is a limit for short variable declarations. <span class="tmd-bold">In a short variable declaration, all items at the left of the <code class="tmd-code-span">:=</code> sign must pure identifiers.</span> This means some other items which can be assigned to, which will be introduced in other articles, can't appear at the left of <code class="tmd-code-span">:=</code>. These items include qualified identifiers, container elements, pointer dereferences and struct field selectors. Pure assignments have no such limit.
</div>
</div>
</div>
<p></p>
<h4 class="tmd-header-4">
About the terminology "assignment"
</h4>
<p></p>
<div class="tmd-usual">
Later, when the word "assignment" is mentioned, it may mean a pure assignment, a short variable declaration, or a variable specification with initial values in a standard variable declaration. In fact, a more general definition also includes <a href="function-declarations-and-calls.html#call">function argument passing</a> introduced in a follow-up article.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
We say <span class="tmd-bold"><span class="tmd-italic"><code class="tmd-code-span">x</code> is assignable to <code class="tmd-code-span">y</code></span></span> if <code class="tmd-code-span">y = x</code> is a legal statement (compiles okay). Assume the type of <code class="tmd-code-span">y</code> is <code class="tmd-code-span">Ty</code>, sometimes, for description convenience, we can also say <span class="tmd-bold"><span class="tmd-italic"><code class="tmd-code-span">x</code> is assignable to type <code class="tmd-code-span">Ty</code></span></span>.
</div>
<p></p>
<div class="tmd-usual">
Generally, if <code class="tmd-code-span">x</code> is assignable to <code class="tmd-code-span">y</code>, then <code class="tmd-code-span">y</code> should be mutable, and the types of <code class="tmd-code-span">x</code> and <code class="tmd-code-span">y</code> are identical or <code class="tmd-code-span">x</code> can be implicitly converted to the type of <code class="tmd-code-span">y</code>. Surely, <code class="tmd-code-span">y</code> can also be the blank identifier <code class="tmd-code-span">_</code>.
</div>
<p></p>
<h4 class="tmd-header-4">
Each local declared variable must be used at least once effectively
</h4>
<p></p>
<div class="tmd-usual">
Please note, the standard Go compiler and gccgo both don't allow local variables declared but not used. Package-level variables have no such limit.
</div>
<p></p>
<div class="tmd-usual">
If a local variable is only ever used as destination values, it will also be viewed as unused. For example, in the following program, <code class="tmd-code-span">r</code> is only used as destination.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

// Some package-level variables.
var x, y, z = 123, true, "foo"

func main() {
	var q, r = 789, false
	r, s := true, "bar"
	r = y // r is unused.
	x = q // q is used.
}
</code></pre>
<div class="tmd-usual">
Compiling the above program will result to the following compilation errors (assume the source file is name <code class="tmd-code-span">example-unused.go</code>):
</div>
<p></p>
<pre class="tmd-code output">
./example-unused.go:6:6: r declared and not used
./example-unused.go:7:16: s declared and not used
</pre>
<p></p>
<div class="tmd-usual">
The fix is easy, we can assign <code class="tmd-code-span">r</code> and <code class="tmd-code-span">s</code> to blank identifiers to avoid compilation errors.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

var x, y, z = 123, true, "foo"

func main() {
	var q, r = 789, false
	r, s := true, "bar"
	r = y
	x = q

	_, _ = r, s // make r and s used.
}
</code></pre>
<p></p>
<div class="tmd-usual">
Generally, the above fix is not recommended to be used in production code. It should be used in development/debug phase only. It is not a good habit to leave unused local variables in code, for unused local variables have negative effects on both code readability and program execution performance.
</div>
<p></p>
<h4 class="tmd-header-4">
Dependency relations of package-Level variables affect their initialization order
</h4>
<p></p>
<div class="tmd-usual">
For the following example,
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">var x, y = a+1, 5         // 8 5
var a, b, c = b+1, c+1, y // 7 6 5
</code></pre>
<p></p>
<div class="tmd-usual">
the initialization order of the package-level variables are <code class="tmd-code-span">y = 5</code>, <code class="tmd-code-span">c = y</code>, <code class="tmd-code-span">b = c+1</code>, <code class="tmd-code-span">a = b+1</code>, and <code class="tmd-code-span">x = a+1</code>.
</div>
<p></p>
<div class="tmd-usual">
Here, the <code class="tmd-code-span">+</code> symbol is the addition operator, which will be introduced in the next article.
</div>
<p></p>
<div class="tmd-usual">
Package-level variables can't be depended circularly in their declaration. The following code fails to compile.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">var x, y = y, x
</code></pre>
<p></p>
<h3 class="tmd-header-3">
Value Addressability
</h3>
<p></p>
<div class="tmd-usual">
In Go, some values are addressable (there is an address to find them). All variables are addressable and all constants are unaddressable. We can learn more about addresses and pointers from the article <a href="pointer.html">pointers in Go</a> and learn other addressable and unaddressable values from other articles later.
</div>
<p></p>
<p></p>
<h3 class="tmd-header-3">
Explicit Conversions on Non-Constant Numeric Values
</h3>
<p></p>
<div class="tmd-usual">
In Go, two typed values of two different basic types can't be assigned to each other. In other words, the types of the destination and source values in an assignment must be identical if the two values are both basic values. If the type of the source basic value is not same as the type of the destination basic value, then the source value must be explicitly converted to the type of the destination value.
</div>
<p></p>
<div class="tmd-usual">
As mentioned above, non-constant integer values can be converted to strings. Here we introduce two more legal non-constant numeric values related conversion cases.
</div>
<p></p>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
Non-constant floating-point and integer values can be explicitly converted to any other floating-point and integer types.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
Non-constant complex values can be explicitly converted to any other complex types.
</div>
</li>
</ul>
<p></p>
<div class="tmd-usual">
Unlike constant number conversions, overflows are allowed in non-constant number conversions. And when converting a non-constant floating-point value to an integer, rounding is also allowed. If a non-constant floating-point value doesn't overflow an integer type, the fraction part of the floating-point value will be discarded (towards zero) when it is converted to the integer type.
</div>
<p></p>
<div class="tmd-usual">
In all non-constant conversions involving floating-point or complex values, if the result type cannot represent the value, then the conversion succeeds but the result value is implementation-dependent.
</div>
<p></p>
<div class="tmd-usual">
In the following example, the intended implicit conversions at line <span class="tmd-italic">7</span> and line <span class="tmd-italic">18</span> both don't work. The explicit conversions at line <span class="tmd-italic">5</span> and line <span class="tmd-italic">16</span> are also disallowed.
</div>
<p></p>
<pre class="tmd-code line-numbers must-line-numbers">
<code class="language-go">const a = -1.23
// The type of b is deduced as float64.
var b = a
// error: constant 1.23 truncated to integer.
var x = int32(a)
// error: cannot assign float64 to int32.
var y int32 = b
// okay: z == -1, and the type of z is int32.
//       The fraction part of b is discarded.
var z = int32(b)

const k int16 = 255
// The type of n is deduced as int16.
var n = k
// error: constant 256 overflows uint8.
var f = uint8(k + 1)
// error: cannot assign int16 to uint8.
var g uint8 = n + 1
// okay: h == 0, and the type of h is uint8.
//       n+1 overflows uint8 and is truncated.
var h = uint8(n + 1)

</code></pre>
<p></p>
<div class="tmd-usual">
We can think that value <code class="tmd-code-span">a</code> at line <span class="tmd-italic">3</span> is implicitly converted to its default type (<code class="tmd-code-span">float64</code>), so that the type of <code class="tmd-code-span">b</code> is deducted as <code class="tmd-code-span">float64</code>. More implicit conversion rules will be introduced in other articles later.
</div>
<p></p>
<h3 class="tmd-header-3">
Scopes of Variables and Named Constants
</h3>
<p></p>
<div class="tmd-usual">
In Go, we can use a pair of <code class="tmd-code-span">{</code> and <code class="tmd-code-span">}</code> to form a code block. A code block can nest other code blocks. A variable or a named constant declared in an inner code block will shadow the variables and constants declared with the same name in outer code blocks. For examples, the following program declares three distinct variables, all of them are called <code class="tmd-code-span">x</code>. An inner <code class="tmd-code-span">x</code> shadows an outer one.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

const y = 789
var x int = 123

func main() {
	// The x variable shadows the above declared
	// package-level variable x.
	var x = true

	// A nested code block.
	{
		// Here, the left x and y are both
		// new declared variable. The right
		// ones are declared in outer blocks.
		x, y := x, y

		// In this code block, the just new
		// declared x and y shadow the outer
		// declared same-name identifiers.
		x, z := !x, y/10 // only z is new declared
		y /= 100
		println(x, y, z) // false 7 78
	}
	println(x) // true
	println(z) // error: z is undefined.
}
</code></pre>
<p></p>
<div class="tmd-usual">
The scope (visibility range in code) of a package-level variable (or a named constant) is the whole package of the variable (or the named constant) is declared in. The scope of a local variable (or a named constant) begins at the end of its declaration and ends at the end of its innermost containing code block. This is why the last line in the <code class="tmd-code-span">main</code> function of the above example doesn't compile.
</div>
<p></p>
<div class="tmd-usual">
Code blocks and identifier scopes will be explained in detail in <a href="blocks-and-scopes.html">blocks and scopes</a> later.
</div>
<p></p>
<p></p>
<h3 class="tmd-header-3">
More About Constant Declarations
</h3>
<p></p>
<h4 class="tmd-header-4">
The value denoted by an untyped constant can overflow its default type
</h4>
<p></p>
<div class="tmd-usual">
For example, the following code compiles okay.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">// 3 untyped named constants. Their bound
// values all overflow their respective
// default types. This is allowed.
const n = 1 &lt;&lt; 64          // overflows int
const r = 'a' + 0x7FFFFFFF // overflows rune
const x = 2e+308           // overflows float64

func main() {
	_ = n &gt;&gt; 2
	_ = r - 0x7FFFFFFF
	_ = x / 2
}
</code></pre>
<p></p>
<div class="tmd-usual">
But the following code does't compile, for the constants are all typed.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">// 3 typed named constants. Their bound
// values are not allowed to overflow their
// respective default types. The 3 lines
// all fail to compile.
const n int = 1 &lt;&lt; 64           // overflows int
const r rune = 'a' + 0x7FFFFFFF // overflows rune
const x float64 = 2e+308        // overflows float64
</code></pre>
<p></p>
<h4 class="tmd-header-4">
Each named constant identifier will be replaced with its bound literal value at compile time
</h4>
<p></p>
<div class="tmd-usual">
Constant declarations can be viewed as enhanced <code class="tmd-code-span">#define</code> macros in C. A constant declaration defines a named constant which represents a literal. All the occurrences of a named constant will be replaced with the literal it represents at compile time.
</div>
<p></p>
<div class="tmd-usual">
If the two operands of an operator operation are both constants, then the operation will be evaluated at compile time. Please read the next article <a href="operators.html">common operators</a> for details.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
For example, at compile time, the following code
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

const X = 3
const Y = X + X
var a = X

func main() {
	b := Y
	println(a, b, X, Y)
}
</code></pre>
<p></p>
<div class="tmd-usual">
will be viewed as
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

var a = 3

func main() {
	b := 6
	println(a, b, 3, 6)
}
</code></pre>
<p></p>
</div>
